1. Technical Field
The present invention relates to data storage and retrieval generally and more particularly to a method and system of providing access to a virtual storage device.
2. Description of the Related Art
Information drives business. For businesses that increasingly depend on data and information for their day-to-day operations, unplanned downtime due to data loss or data corruption can damage their reputations and bottom lines. Data can be corrupted or lost due to hardware and/or software failure, user error, and/or intentional malicious action. To increase data consistency and integrity and minimize the impact of data corruption, a number of techniques have been developed and implemented. One such technique involves the generation of backup or “snapshot” data which may be utilized in the event corruption of “primary” or “production” data occurs.
Such a snapshot is typically generated by first mirroring data from a primary data storage area to a backup, or “mirror” storage area in real time as updates are made to the primary data. Periodic “snapshots” of data may then be generated by “detaching” a mirror being updated in real time so that it is no longer updated. Detaching the mirror involves halting transactions being applied to the primary data storage area and to the mirror for a very brief time period to allow existing transactions to complete. A snapshot is then taken which serves as a frozen or “point-in-time” image, and provides a logically consistent copy of, the primary data. Such snapshot data may be useful in performing backups, data analysis, etc., and to recover from unintentional or unforeseen data corruption (e.g., where snapshot data is created on a regular or periodic basis) as well as to perform “provisional” write operations or updates, further described herein, to avoid data corruption resulting from anticipated or intentional data changes (e.g., where snapshot data is created on-demand prior to an update).
FIGS. 1A and 1B illustrate the generation of a snapshot within a data storage system according to the prior art. In FIG. 1A, two mirrors of data 110 are maintained within a storage environment 100, and corresponding updates are made to mirrors 120A and 120B when an update, such as update 104A, is made to data 110. For example, update 104B is made to mirror 120A residing on mirror data storage area 122, and corresponding update 104C is made to mirror 120B residing on mirror data storage area 124 when update 104A is made to data 110. In a conventional data storage system, each mirror may reside on a separate physical storage device from the data for which the mirror serves as a backup, and therefore, data storage areas 112, 122, and 124 correspond to three physical storage devices in the illustrated example.
A snapshot of data can then be made by “detaching,” or “splitting,” a mirror of the data so that the mirror is no longer being updated. FIG. 1B shows storage environment 100 after detaching mirror 120B. Detached mirror (snapshot) 120B serves as a snapshot of data 110 as it appeared at the point in time that mirror 120B was detached. When another update 106A is made to data 110, a corresponding update 106B is made to mirror 120A. However, no update is made to detached mirror (snapshot) 120B. Instead, a pointer to the data changed in update 106A is retained in a data change log 130 which tracks changes in primary data with respect to detached mirror (snapshot) 120B.
In a typical data storage system resynchronization allows snapshots to be refreshed and re-used rather than discarded. A snapshot such as snapshot 120B can be quickly re-associated with the primary data which it previously mirrored in a process sometimes referred to as a “snapback.” Updates made to the primary volume while the snapshot was unavailable for update are tracked using data change log 130. When the snapshot is “re-attached” to again serve as a mirror, only the updates that were missed are applied to re-synchronize the snapshot with the primary data. For example, if the storage device storing detached mirror (snapshot) 120B will be again used to serve as a mirror for production data, an update applying the change made in update 106A would be applied to snapshot 120B before other updates are made.
According to one known process, a provisional write operation or update is performed on a snapshot in order to avoid the corruption and/or loss of primary data. A snapshot is first generated as described herein and a desired operation is performed on the snapshot. The result of performing the operation on the snapshot may then be analyzed to determine the effect the operation would have had on the primary data. Thereafter, the snapshot may be accessed, resynchronized or “snapped-back” to the primary, or discarded as desired. Although this technique preserves the integrity of primary data while allowing a user to “test” the impact of an operation, it requires the creation of a separate snapshot for each provisional operation to be carried out and the time and storage resources associated with the snapshot may be forfeited if a snapback operation is not ultimately performed. Consequently, and due to other negative associated attributes, the described process has proven to be undesirable.